Method And System For Secure Authenticated Payment On A Computer Network

ABSTRACT

A simple, secure and easy-to-deploy method and system for authenticating credit and debit cardholders at the point-of-sale on a computer network (e.g., the Internet) is disclosed. Cardholders are authenticated using digital signatures on a sales draft, in a manner that does not necessarily require any changes in the transaction flow of the participating financial institutions.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation and claims the benefit of co-pending,commonly assigned U.S. patent application Ser. No. 11/105,195, filedApr. 12, 2005, entitled “Method And System For Secure AuthenticatedPayment On A Computer Network,” which is a continuation and claims thebenefit of commonly assigned U.S. patent application Ser. No.09/437,065, filed Nov. 9, 1999, entitled “Method And System For SecureAuthenticated Payment On A Computer Network,” issued as U.S. Pat. No.6,895,391 on May 17, 2005, the entire disclosure of each of which isherein incorporated by reference for all purposes.

FIELD OF THE INVENTION

The present invention relates to a method and system for secureauthenticated payment at a point-of-sale on a computer network. Moreparticularly, the present invention allows the use of digital signatureson a sales draft to authenticate purchasers in a manner that does notnecessarily require any changes in the transaction processing of thefinancial institutions participating in the transaction.

BACKGROUND OF THE INVENTION

In present electronic commerce transactions, buyers may pay for goodsand services by presenting the seller with a payment card number, e.g.,a conventional credit card number.

Because the buyer and seller are connected solely through a computernetwork (e.g., the Internet), it is not possible for the buyer toauthenticate himself as the legitimate cardholder, nor can the buyersign the sales draft. Thus, the seller honors any valid credit cardnumber that is presented, creating a large opportunity for fraud.

Worse yet, other forms of payment such as debit cards are not presentlyviable on computer networks. Debit cards require the cardholder to entera personal identification number (“PIN”), which is used to authenticatethe transaction to the cardholder's bank. However, entering a simple PINon a networked computer poses a substantial security risk-if the PIN andthe debit-card number fell into the wrong hands, the cardholder's bankaccount would be completely compromised.

Thus, with respect to both conventional credit and debit cards,authenticating a cardholder on the network with a solution that issimple, secure, and easy to deploy remains an important unsolvedproblem.

Digital signature technology offers one means of authenticating thecardholder with a high degree of security. In this technology, eachcardholder owns a pair of keys-a signature (private) key and averification (public) key. The cardholder signs a transaction with hisprivate key, and then sends the transaction, the digital signature, and(optionally) his public key to the merchant. The merchant forwards theseitems to the bank (or other financial institution), and the bank honorsthe transaction if the cardholder's public key verifies the cardholder'sdigital signature.

One security advantage of digital signatures is that the private key ofthe cardholder typically remains in possession (or at least control) ofthe cardholder. Thus, there is no inherent risk associated with atransaction that would compromise future transactions. One disadvantageof the digital signature method described above is that banks andtransaction processors would have to change their existinginfrastructure to allow digital signatures to flow through theirnetworks. This infrastructure change would basically require asubstantial overhaul of the present electronic banking and transactionprocessing system, which is costly and difficult to achieve.

Thus, there is a need for a method and system that offers the securityadvantages of digital signatures without necessarily requiringsignificant changes in the banking and processing network.

BRIEF SUMMARY OF THE INVENTION

One embodiment of the present invention includes a simple, secure andeasy-to-deploy method and system for authenticating credit and/or debitcardholders at a point-of-sale on a computer network (e.g., theInternet). Cardholders are authenticated using digital signatures on asales draft, in a manner that does not necessarily require any changesin the transaction process of the financial institutions participatingin the transaction.

In this embodiment of the system, the cardholder enrolls for anelectronic payment card (either an electronic debit or credit card) at aparticipating financial institution by visiting its issuer proxyenrollment site, e.g., a web site hosted by an issuer proxy computerassociated with the financial institution. At the enrollment site, thecardholder types in his particulars, such as his conventional paymentcard number, conventional payment card PIN, name, address, etc. Thecardholder also (optionally) selects a password (access code) for hiselectronic payment card that is preferably unrelated to the PIN for hisconventional payment card. The issuer proxy generates a publickey-private key pair for use by the cardholder if the cardholder doesnot already have such a pair. The issuer proxy binds the cardholder'spublic key and some or all of the cardholder's payment particulars in adigital certificate using an encryption key (called a domain key) thatis shared between the issuer proxy and a bridge computer. Such a domainkey will allow the bridge computer to confirm the issuer's certificationduring a subsequent authorization stage, described below. The cardholderthen receives a piece of software that is downloaded to his computercontaining his particulars in encrypted form. This piece of softwareconstitutes the cardholder's electronic payment card. It comprises (oris configured to obtain and use) the cardholder's private key, which is(optionally) protected by the password, and the corresponding public-keydigital certificate containing the cardholder's payment particulars.

Thenceforth, as the cardholder shops online, he can elect to pay viaelectronic payment. To do so, the cardholder activates his electronicpayment card with the previously selected password. The cardholder'selectronic payment card software interacts with corresponding softwareat the online merchant to digitally sign the sales draft created duringthe transaction with the cardholder's private key. The merchant thensends the signed sales draft and the cardholder's digital certificate tothe bridge computer for processing. The bridge computer uses thecardholder's digital certificate to check the digital signature on thesales draft. If the signature is valid, the bridge computer creates aconventional debit or credit transaction to be processed by the bankingand transaction network. The particulars needed for creating theconventional transaction, such as the conventional card number and PIN,are extracted and decrypted from the cardholder's digital certificateusing the private key associated with the domain key (if the digitalcertificate was asymmetrically encrypted) or the domain key itself (ifthe digital certificate was symmetrically encrypted). The embodiment ofthe invention described above provides one or more or the followingadvantages:

-   -   (1) Additional hardware at the cardholder's computer is not        necessarily required for deployment. This is in marked contrast        to hardware tokens such as smart cards, where cards and card        readers are required. Of course, the software comprising the        cardholder's electronic payment card can be stored on smart        cards, as well as virtually any other storage medium, including,        without limitation, floppy disks, hard drives, and magnetic        stripe cards;    -   (2) Changes are not necessarily required in the existing banking        network;    -   (3) Administrative overhead is low. The cardholder can enroll at        any participating financial institution that offers the service,        not necessarily the one that issued the cardholder's        conventional payment card. Furthermore, enrollment can be on a        self-serve basis and does not necessarily require activation        mailings by the financial institutions;    -   (4) Electronic payment cards can be deployed rapidly, because        they are intuitive to use and require little user or        administrator training; and/or    -   (5) Security can be enhanced via special techniques such as        “cryptographic camouflaging,” which is commercially available        from Arcot Systems, Inc.

The foregoing and other embodiments and aspects of the present inventionwill become apparent to those skilled in the art in view of thesubsequent detailed description of the invention taken together with theaccompanying figures and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary computer system forsecure authenticated payment on a computer network.

FIG. 2 is a flow chart illustrating an exemplary method for cardholderenrollment for an electronic payment card.

FIG. 2A illustrates an exemplary electronic payment card created usingthe preferred embodiment of the invention.

FIG. 3 is a flow chart illustrating an exemplary method forpoint-of-sale interaction between a cardholder and a merchant.

FIG. 4 is a flow chart illustrating an exemplary method for a merchantto obtain authorization for the payment transaction.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram illustrating an exemplary computer system forsecure authenticated payment on a computer network (e.g., the Internet).The system contemplates a network of computers including a cardholder'scomputer 100, a payment card issuer's proxy computer 110, a merchant'scomputer 120, a bridge computer 130, a payment gateway computer 140, andlegacy back end computer 150. In this exemplary embodiment, the networkis deployed over the Internet, although those skilled in the art willrecognize that any public or private communication network including,without limitation, extranets, intranets, and other telephonic or radiocommunications networks could also be used. Similarly, as used herein,the term computer refers to any device that processes information usingan integrated circuit chip, including without limitation mainframecomputers, work stations, servers, desktop computers, portablecomputers, embedded computers, and hand-held computers.

Enrollment

Referring now to FIG. 2, at step 200, a cardholder (user) at computer100 enrolls for an electronic payment card (either an electronic debitcard or an electronic credit card) at the electronic payment card issuerproxy 110, typically by visiting the website of a participatingfinancial institution on the Internet. At step 210, the cardholderprovides the issuer 110 with particular information used to make apayment (payment particulars), such as his conventional payment cardnumber, conventional payment card PIN, conventional credit card holderverification value 2 (“CVV2”), conventional cardholder name and address,or any other cardholder identification information. The issuer proxy 110can be operated by any trusted financial institution that participatesin the electronic payment system, not necessarily the financialinstitution that issued the cardholder's conventional payment card.

The issuer proxy 110 can optionally verify the cardholder's paymentinformation by any of the means available for such verificationincluding, without limitation, creating a payment transaction in theconventional payment network. Such a transaction could be “authorizationonly” in the sense that it would be used only for verifying thecardholder's payment particulars, with no money actually transferred.

At step 220, the issuer 110 generates a public key-private key pair forthe cardholder to use in connection with the electronic payment system.If the cardholder already has a public key-private key pair that hewishes to use in connection with the electronic payment system, heprovides his public key to the issuer 110. The cardholder's private keyis typically stored on the cardholder's computer 100, often under thecontrol of a PIN or other form of access code (password). The accesscode can be protected against unauthorized detection using commerciallyavailable software technology such as software smart cards from ArcotSystems, Inc., described in “Software Smart Cards via CryptographicCamouflage,” Proceedings IEEE Symposium on Security and Privacy, May1999, and in U.S. patent application Ser. No. 08/996,758, “Method andApparatus For Secure Cryptographic Key Storage Certification And Use,”now U.S. Pat. No. 6,170,058, which is incorporated herein by reference.

The access code may also be protected against unauthorized detection(e.g., so-called “shoulder surfing”) using the technology described inU.S. patent application Ser. No. 09/249,043, “Method And Apparatus ForSecure Entry Of Access Codes In A Computer Environment,” now U.S. Pat.No. 6,209,102, which is incorporated herein by reference.

At step 230, the issuer 110 binds the cardholder's public key and someor all of the cardholder's payment particulars in a digital certificate,typically by encrypting the cardholder's public key and particularidentifying information provided by the cardholders The encryption keyused for encrypting the cardholder's payment particulars—called thedomain key—is typically shared between the issuer proxy 110 and thebridge computer 130, and may be either a symmetric key or an asymmetricencryption key. In one embodiment, the domain key may be a public keyassociated with the bridge computer 130, so that only the bridgecomputer 130 can decrypt the encrypted cardholder particulars (using acorresponding private key associated with the bridge computer 130). Inanother embodiment, the domain key may be a symmetric encryption keythat is shared by the issuer proxy 110 and the bridge computer 130. Ineither case, the bridge computer will use the domain key (actually, itsprivate key counterpart, if asymmetric; or the domain key itself, ifsymmetric) to verify the binding, as will be described later in thesection entitled “Authorization.” After the issuer proxy 110 combinesthe cardholder's public key with some or all of the cardholder's paymentinformation and digitally signs the combination to create a digitalcertificate for the cardholder, the digital certificate for thecardholder is loaded into an electronic payment card for the cardholder.Of course, those skilled in the art will realize that many other typesof binding can be used including, without limitation, offloading thesigning to a trusted third party, or receiving (rather than creating)the digital certificate from the user (although such binding is lesssecure).

At step 240, the issuer 110 sends and the cardholder's computer 100receives the cardholder's electronic payment card, e.g., a piece ofsoftware that is downloaded to the cardholder's computer 100. Theelectronic payment card (typically stored in a software wallet) may befurther protected against unauthorized access via a PIN (preferablydifferent from the PIN associated with the cardholder's conventionalpayment card) or other form of user access code. The access code may beprotected against unauthorized detection by the above-mentionedprocedures used to protect the private key PIN. (Indeed, if the two PINsare the same, private key access for digitally signing and electronicpayment card access for transaction execution could be accessed via asingle protocol.) Setting the access code (PIN) for the electronicpayment card is preferably done when the electronic payment card isbeing created by the issuer 110, but can also be done separately, e.g.,when the cardholder first accesses his electronic payment card on thecardholder computer 100.

Alternatively, if the cardholder wishes to be able to perform electronictransactions from a variety of locations, the cardholder's private keyand/or electronic payment card may be stored at a credential server anddownloaded on the fly by a roaming cardholder using a shared secret orchallenge-response protocol. In the latter case, commercially availablesoftware such as Arcot Web Fort from Arcot Systems, Inc., described athttp://www.arcot.com/products.html and in U.S. patent application Ser.No. 09/196,430, “Method And Apparatus For Secure Distribution OfAuthentication Credentials To Roaming Users,” now U.S. Pat. No.6,263,446, which is hereby incorporated by reference, may be used toeffect the roaming functionality.

One advantage of this enrollment process is that the issuer'sparticipation can be passive, in that the issuer proxy 110 can beoperated by any trusted financial institution that participates in theelectronic payment system, and is not necessarily the bank or financialinstitution that issued the conventional payment card to the cardholder.This is important because it suffices that one well-recognized financialinstitution participates in the system. Furthermore, even theparticipation of this financial institution can be limited toestablishing the issuer proxy 110 on the network for self-service accessby the cardholder, and does not require mailings to the cardholder, orother physical interaction with the cardholder.

FIG. 2A illustrates an exemplary electronic payment card created usingthe preferred embodiment of the invention, in which the card contains:(a) the cardholder's digital certificate, comprising the cardholder'spayment particulars, and his public key, portions of which are encryptedunder the domain key; and (b) the cardholder's private key.

Point-of-Sale Transaction Between a Cardholder and a Merchant on theComputer Network

A cardholder uses his computer 100 to shop at a merchant's website atmerchant's computer 120. Referring now to FIG. 3, at step 300, when thecardholder decides what goods or services he wants to buy, the merchantpresents the cardholder with an electronic sales draft.

At step 310, the cardholder elects to pay the sales draft using thecardholder's electronic payment card. At step 320, a representation ofthe cardholder's electronic payment card may be displayed on thecardholder's computer 100. If the cardholder chose to protect hiselectronic payment card with an access code, then at step 330 thecardholder unlocks and activates his electronic payment card. If theelectronic payment card is protected with an access code, then theelectronic payment card cannot be activated unless the correct accesscode is entered. The access code can be stored in a variety of locationsincluding, without limitation, the cardholder's own memory, or a floppydisk, magnetic stripe card, smart card, or disk drive coupled to thecardholder's computer 100. At step 340, the cardholder's (activated)electronic payment card digitally signs the electronic sales draft thatwas presented to the cardholder in step 300 using the cardholder'sprivate key. Optionally, the cardholder's electronic payment card canautomatically fill in the information used by the sales draft. At step350, the cardholder's computer 100 sends the digitally signed salesdraft and the cardholder's digital certificate to the merchant'scomputer 120, where it is received by the merchant's computer 120.

Authorization

Referring now to FIG. 4, at step 400, the merchant's computer 120 sends,and the bridge computer 130 receives, an authorization request from themerchant (seller). The authorization request includes the electronicsales draft with the cardholder's (buyer's) electronic signature and thecardholder's digital certificate. As mentioned above, in one embodimentof the invention, the cardholder's digital certificate includes thecardholder's verification key (public key) and an encrypted version ofthe cardholder's PIN for his conventional payment card.

At step 410, the bridge computer 130 uses the cardholder's verificationkey to confirm (verify) that the cardholder's electronic signature onthe sales draft was authorized by the cardholder (buyer). If theelectronic signature is confirmed, then at step 420 the bridge computer130 extracts the encrypted version of the cardholder's PIN for hisconventional payment card from the cardholder's digital certificate anddecrypts the PIN using the private key associated with the domain key(if the PIN was asymmetrically encrypted) or the domain key itself (ifthe PIN was symmetrically encrypted). In this (or in some equivalent)fashion, the bridge computer 130 can verify the binding (of the paymentparticulars and the user's public key) that was performed by the issuer110. The bridge computer 130 uses the decrypted PIN to generate aconventional authorization request as is well-known to those skilled inthe art of payment card transaction processing (see, e.g., VisaInternational Acquirer Services External Interface Specification, Apr.1, 1999, EIS 1080 Version 5.8, available from Visa). The decrypted PINmay be re-encrypted with a key that is shared by the bridge computer 130and the transaction processor at payment gateway 140. Certain otherparticulars that are typically used for creating a conventionalauthorization request, such as the conventional payment card number,conventional credit card holder verification value 2 (“CVV2”),conventional cardholder name and address, or any other cardholderidentification information, may also be extracted and decrypted from thecardholder's digital certificate.

Note that some types of conventional payment transactions do notnecessarily use PINs, e.g., some conventional credit card transactions.For these transactions, after the bridge computer 130 verifies thecardholder's digital signature on the sales draft at step 410, thebridge computer 130 generates a conventional authorization request atstep 420 without performing the PIN extraction and PIN decryption steps.

At step 430, the bridge computer 130 sends the conventionalauthorization request to the transaction processor at payment gateway140. Using the information provided in the authorization request, thepayment gateway 140 approves or denies the request and sends itsauthorization response back to the bridge computer 130.

In an alternative embodiment of the invention, the bridge computer 130can be integrated into the payment gateway 140. Indeed, any combinationof issuer proxy 110, bridge computer 130, and/or payment gateway 140 canbe integrated together.

The bridge computer 130 receives from the payment gateway 140 either anapproval or a disapproval of the authorization request. In either event,at step 440, the bridge computer 130 forwards the authorization response(approval or disapproval) to the merchant (seller) at the merchant'scomputer 120.

If the cardholder is making a debit transaction, then at step 450 themerchant's computer 120 sends a confirmation to the payment gateway 140via the bridge computer 130.

One advantage of this authorization process is that there is minimalimpact on the merchant. Another advantage is that the payment gateway140 can interact with the legacy back-end systems 150 using conventionaltransaction processing methods. In other words, no changes arenecessarily required to the back-end infrastructure.

In an alternate embodiment of the system, the bridge computer 130 canact in “stand-in” mode. Specifically, some financial institutions maychoose not to receive the decrypted PIN from the cardholder's digitalcertificate, relying instead on the bridge computer's assertion that thecardholder's signature verified correctly. If the cardholder PIN wasalso verified at the issuer proxy 110 during enrollment, the risk of afraudulent transaction may be deemed low. In such situations, the bridgecomputer 130 would assemble and transmit an authorization requestwithout a PIN to the transaction processor at payment gateway 140.

In yet another embodiment of the system, the merchant can store a copyof the digital signature of the cardholder along with the sales draft.The bridge computer 130 would process the transaction assuming that thedigital signature of the cardholder is valid. In the event that thecardholder disputes the transaction, the merchant must present thestored copy of the sales draft and the cardholder's digital signature.The bridge computer 130 will verify the digital signature and, on thebasis of the verification, determine whether the merchant should refundthe amount of the transaction. An advantage of this embodiment is thatthe computational processing required at the bridge computer 130 isreduced. However, the merchant faces an increased risk of fraud.

In yet another embodiment of the system, a user who does not have aconventional credit or debit card (or who wants to get additionalconventional payment cards), can be given the option of signing up for aconventional payment card during the electronic payment card enrollmentprocess. The conventional payment card number that is given to this usercan then be incorporated into the user's electronic payment card.

In yet another embodiment of the system, a user may choose to enroll hischecking account to an electronic payment credential, rather than adebit or credit card. The user would identify himself via a variety ofmeans at enrollment time, or may be given an activation code by his bankthat he would use to identify himself for enrollment.

Although the preferred embodiments of this invention create anelectronic payment card for conventional debit or credit cards orconventional checking accounts, the present invention enables a bridgeto network payment for almost any conventional transaction system. Forexample, the present invention could also be used for secure electronicbill payment, person-to-person transactions, and electronic auctionsettlements.

The software described herein, for use by the various computers, isconveniently implemented using C, C++, Java, Javascript, HTML, or XML,running on Windows, Windows NT, Solaris, Unix, Linux, or Macintoshoperating systems on virtually any computer platform. Moreover, thoseskilled in the art will readily appreciate that such software can beimplemented using virtually any programming language, running onvirtually any operating system on any computer platform.

The various embodiments described above should be considered as merelyillustrative of the present invention. They are not intended to beexhaustive or to limit the invention to the forms disclosed. Thoseskilled in the art will readily appreciate that still other variationsand modifications may be practiced without departing from the generalspirit of the invention set forth herein. Therefore, it is intended thatthe present invention be defined by the claims that follow.

1. A method for authenticating an electronic payment comprising:receiving from a seller an electronic sales draft including anelectronic signature; receiving from said seller a digital certificateassociated with a buyer, said digital certificate including averification key and an encrypted version of a personal identificationnumber (PIN); using said verification key to verify that said electronicsignature was authorized by said buyer; extracting said encryptedversion of said PIN from said digital certificate; decrypting saidencrypted version of said PIN; generating, using said PIN, anauthorization request; sending said authorization request for a PIN to afinancial institution; receiving an approval of said authorizationrequest from said financial institution; and sending said approval tosaid seller.